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Method and system for routing and controlling packet data flow 
Menetelma ja jarjestelma pakettidatan reitittSmiseksi ja vuon valvomiseksi 
5 £tt forfarande och ett system fSr att addressera och kontrollera paketdata flux 

The present invention relates generally to teleconamunication systems. In particular the 
\ invention concerns routing and controlling the flow of packet data transmissions in a 

mobile network. 

10 

-» 3GPP (3^^ Generation Partnership Project) has recently published a specification for 

the 3GPP system comprising either UTRAN (UMTS Terrestrial Radio Access 
Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access network. 
The specification defines a new broadcast/multicast service tided MBMS (Multimedia 
15 Broadcast/Multicast Service) [1], MBMS basic architecture is illustrated in figure 1 
wherein CBC (Cell Broadcast Centre) 102, CSE (Camel Service Environment) 108, 
OSA/SCS (Open Service Access) 112 and related reference points can be considered 
as optional functionalities. Accordingly, mandatory components for realizing a MBMS 
service are described next in reference to [2]. 

20 

s"-,: The SGSN (Serving GPRS Support Node) 120 executes user specific service control 

ro\ functions, concentrates individual users of the same MBMS service into a single 

MBMS service and maintains a single connection with the soiurce of the MBMS data. 
^[J. The SGSN 120 may also authenticate users and authorise the usage of services based 

\ \ 25 on subscription data from the HLR (Home Location Register) 106. The GGSN 
V!" (Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS Tunneling 

^•o' Protocol) tunnels from the SGSN 120 and links these tunnels via IP (Internet Protocol) 

multicast with the MBMS data source. The BM-SC (Broadcast/Multicast Service 
Centre) 110 is an MBMS data source. The architecture also accepts other MBMS 
30 broadcast/multicast data sources and intemal data sources 104 may directiy provide 
their data. Data delivery by extemal sources 126 is controlled by Border Gateways 
f • (BG) 124 which may allow for example data from single addresses and ports to pass 

,:o" into the PLMN (Public Land Mobile Network) for delivery by an MBMS service. 

""•^ MBMS data may be scheduled in the BM-SC 1 10, for example, to be transnaitted to the 

\l 35 user every hour. It offers interfaces which can be utilized by a content provider 104, 
Ij; 1 14 in requesting data deUvery to users. The BM-SC 1 10 may authorise and charge the 

content provider 104, 114. The Gmb reference point between BM-SC 110 and GGSN 
122 enables the BM-SC 110 to exchange MBMS service control information with the 
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GrGSN 122. The Gmb reference point exists in order to carry the MBMS service 
information but it may not always be necessary to use the Gmb for each service. 
MBMS service can be delivered to user equipment (UE) 116, 128 such as a mobile 
terminal over GERAN 130 or UTRAN 118. 

5 

The architecture assumes the use of BP multicast at the reference point Gi. The MBMS 
data source has only one connection to the IP backbone. The reference point from the 
content provider to the BM-SC 110 is currently not standardized as it might become 
too complex or restrictive for service creation. For example, this may be a reference 
10 point between the BM-SC 110 and an authoring system, or the authoring functionality 
may be distributed between both entities. The same architecture provides MBMS 
broadcast services mainly by using the transport functions. The user individual SGSN 
functions are not required. Instead each individual broadcast service is configured in 
the SGSN 120. 

15 

The SGSN 120 may use CAMEL (Customised AppUcation for Mobile network 
Enhanced Logic) to handle pre-paid services, e.g. credit checking for on-line charging. 
The Cell Broadcast Centre (CBC) 102 may be used to announce MBMS services to the 
users. The BM-SC 110 may exploit OSA-SCS 112 to mteract with third parties. For 
20 the terminal split, MBMS shall be able to interoperate with an IP multicast client 
software on the terminal. More detailed information about MBMS service 
activation/release models, data transfer, functionalities of network elements, radio 
interface bearer set-up/release, QoS (Quality of Service), security issues etc. can be 
oopo ! found in the references [1] and [2] . 

« As depicted in figure 1, GERAN 130 can be connected to the core network either 

through lu or Gb interface. lu interface connects the GERAN 130 to 3G SGSN 120. 
The protocols and the functional split between the radio access network and the core 
network are in that case the same for UTRAN 118 and GERAN 130. See figure 2 for 
^ ^ 30 the illustration of user plane protocol stack in lu mode. Packet Data Convergence 
Protocol (PDCP) maps higher-level characteristics onto the characteristics of the 

ooo 

underlying radio-interface protocols thus providing protocol transparency for hi^er- 
layer protocols. GPRS Tunnelling Protocol for the user plane (GTP-U) tunnels user 
data between UTEIAN and the 3G SGSN, and between the GSNs in the backbone 
ol 35 network. GTP encapsulates all PDP (Packet Data Protocol) PDUs (Protocol Data 
I . Unit). UDP/IP (User Datagram Protocol, Internet Protocol) are the backbone network 

protocols used for routing user data and control signalling. The RLC (Radio Link 
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Control) protocol provides logical link control over the radio interface. There may be 
several simultaneous RLC links per terminal. Medium Access Control (MAC) controls 
the access signalling (request and grant) procedures for the radio channel. 

5 Gb interface on the other hand connects the GERAN 130 to 2G SGSN 120 and the 
functional split between the BSS 130 (Base Station System, -radio access network e.g. 
GERAN) and the SGSN 120 is different from the UTRAN/GERAN lu mode. For 
example, ciphering is done in the core network (SGSN). Also the protocol architecture 
illustrated in figure 3 being described more thoroughly later in the text and the 
10 procedures between the SGSN and the BSS differ from the lu case. 

As the MBMS standardization work has so far been mainly focused on the lu interface, 
the procedures presented in the architecture and functional description [2] are 
applicable only for UTRAN/GERAN lu mode. Therefore, new functionality is needed 
15 if MBMS service is introduced into GERAN Gb interface. One specific problem is that 
with Gb interface there is no RAB (Radio Access Bearer) concept in the same way as 
in the lu interface. Thus the procedures corresponding to the MBMS RAB setup, 
release etc. do not apply to the Gb interface. The SGSN establishes RABs basically on 
demand when there exists data to be transferred to the users. 

20 

An option for MBMS (broadcast) service activation and RAB set-up is presented as an 
illustration in figure 4 in reference to [2]. At a SGSN re-start or when a new MBMS 
broadcast service is set-up, see phase 402, the SGSN 120 requests a creation of an 
MBMS context and GTP tunnel on the GGSN 122 for each RNC/BSC (Radio Network 

25 Controller, Base Station Controller) within the service area. In phase 404 the GGSN 
122 joins the relevant IP multicast to connect the BM-SC 1 10 if not connected already. 
In phase 410 the GGSN confirms the establishment of the MBMS context. In phase 
412 MBMS data is sent to the GGSN 122 and in phase 414 forwarded to the SGSN 
120 through all related Gn/Gp tunnels. In phases 416 and 418 a RAB (Radio Access 

30 Bearer) is created for each MBMS context by utilizing assignment request and 
response procedures. In phase 420 MBMS notification is sent to terminals being finally 
followed by the transmission of actual MBMS data in phases 422 and 424. In a 
corresponding multicast case (not shown), the terminal first transmits an Activate 
MBMS Context Request to the SGSN 120, The IP multicast address identifies the 

35 MBMS multicast service, which the terminal wants to join. The SGSN 120 validates 
the Activate MBMS Context Request. The MBMS context(s) store tihie parameters of 
the activated MBMS multicast service. If said terminal is the first one activating tiiis 
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specific MBMS multicast service on the routing area, the SGSN 120 determines the 
RNCs serving the routing area and requests for each the creation of an MBMS context 
on the GGSN 122 and the establishment of a GTP tunnel between the SGSN 120 and 
the GGSN 122. Later in connection with the RAB set-up, the SGSN 120 sends MBMS 
5 RAB Request (indicating e.g. QoS parameters) only to the RNCs serving flie Routing 
Areas in which there are terminals which have joined the MBMS context. 

In addition to arrant data delivery issues, also other aspects remain open in exploiting 
the Gb interface. For example, various applications must not interfere with each other 

10 when the BSS 130 schedules the data transfer over the air interface. Normally both the 
SGSN 120 and BSS 130 have data buffers for data transmission. If the data buffer in 
the BSS 130 fills up because of an overwhelming data flow by a certain MBMS 
service, the transmission of other services using the same data transmission buffer is 
also negatively affected (transmission delays etc). This is one issue that must be taken 

15 into account if MBMS is introduced to the GERAN A/Gb mode as currentiy expected. 

An object of the present invention is to alleviate aforesaid deficiencies and provide an 
addressing mechanism for routing MBMS data over the Gb interface between the 
SGSN 120 and BSS 130. Additionally, a flow control mechanism is needed for MBMS. 

20 services as the bitrate they typically require may be relatively high and varying causing 
potential problems also for other traffic delivered by the BSS 130. The object is 
achieved by introducing a concept of MBMS specific Packet Flow Context (MBPFC; 
Multicast/Broadcast Packet Flow Context) to the Gb interface with functionalities 
partly corresponding the ones MBMS RAB provides in the lu mode. The proposed 

25 concept allows maximum reuse of already-existing procedures and resolves some Gb 
interface specific problems. 

The term "BSS" (Base Station System) refers to a radio access network, e.g. a 
GERAN, comprising at least one base station and radio network controller / base 
30 station controller. 

The term "Gb" refers to an interface between the BSS and second-generation packet- 
switched core network. 
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A method according to the invention for routing MBMS (Multicast/Broadcast 
Multimedia Service) service data from a first network entity to a second network entity 
is characterized in that said method comprises the steps of 



-defining a PFI (Packet How Identifier) associated to at least one MBMS service 
or a group of terminals, 

-creating a PFC (Packet Flow Context) for said MBMS service or group of 
terminals identified by said PFI, 

-transferring the MBMS service data over the Gb interface by utilizing said PFC, 

In another aspect of the invention, a system comprising a Gb interface between a first 
and a second network entity, is characterized in that in order to route MBMS service 
data over said Gb interface said furst and second network entities are arranged to 
negotiate a common PFI (Packet How Identifier) for said MBMS service or a group of 
terminals and said second network element is arranged to create a PFC for said service 
or group of terminals. 

The accompanying dependent claims describe some preferred embodiments of the 
invention. 

In the following, the invention is described in more detail by reference to the attached 
drawings, wherein 

Fig. 1 is a block diagram of an MBMS capable system. 
Fig. 2 is a block diagram of the protocol architecture (user plane) in lu mode. 
Fig. 3 is a block diagram of the protocol architecture (user/control plane) in 
A/Gb mode. 

Fig. 4 is a signalling chart disclosing one option for MBMS Broadcast service 
activation and RAB set-up. 

Fig. 5A is a signalling chart disclosing the messaging applied in the creation of 
MBPFC. 

Fig. 5B is a signalling chart disclosing the messaging applied in the deletion of 
MBPFC. 

Fig. 6 illustrates an option for the message structures applied in the MBPFC 
creation and deletion. 

Fig. 7 presents the layers for controlling the flow of MBMS data routed over the 
Gb interface. 

Fig. 8 discloses a flow diagram of a method for routing and controlling the flow 
of MBMS data in accordance with the invention. 
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Figures 1-4 were already covered in conjimction with the description of prior art. The 
signalling chart in figure 4 presenting the MBMS service activation is feasible also in 
this case what comes to phases 402-414 preceding the RAB set-up. 
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5 The protocol stack of the Gb interface as depicted in figure 3 contains layers titled 
BSSGP (BaseStation System GPRS Protocol) and Network Service (NS). BSSGP 
controls the transfer of LLC (Logical Link Control) frames passed between an SGSN 
and a terminal across the Gb interface. Accordingly, the primary functions of the 
BSSGP include the provision by an SGSN 120 to a BSS 130 of radio related 

10 information used by the RLC/MAC function, the provision by a BSS 130 to an SGSN 
120 of radio related information derived from the RLC/MAC function and the 
provision of functionaUty to enable two physically distinct nodes, an SGSN 120 and a 
BSS 130, to operate node management control functions. BSSGP Virtual Connections 
(BVC) provide communication paths between BSSGP entities. BYCs are identified by 

15 means of a BSSGP Virtual Connection Identifier (BVCI) which has end-to-end 
significance across the Gb interface. Each BVCI is unique between two peer Network 
Service Entities. The Network Service is the entity which actually provides network 
service primitives allowing the transmission and reception of upper layer protocol data 
units between the BSS 130 and SGSN 120. The Network Service is based on the 

20 Frame Relay (FR) connection between the BSS 130 and the SGSN 120, and may multi- 
hop and traverse a network of Frame Relay switching nodes. Each Network Service 
Entity is identified by means of a Network Service Entity Identifier (NSEI) which 
together with the BVCI uniquely identifies a BSSGP Virtual Cormection within an 
SGSN 120. The SGSN 120 needs not to be updated when a new cell (BVC/BVCI) is 

25 added to the BSS (NSEI) 130. The NSEI is used by the BSS 130 and the SGSN 120 to 
determine the NS-VCs that provide service to the BVC. Logical Link Control (LLC) 
offers a ciphered logical link being independent of the underlying radio interface 
protocols in order to allow introduction of altemative GPRS radio solutions with 
minimum changes to the NSS. RLC/MAC contains two functions: The Radio Link 

30 Control function provides a radio-solution-dependent reliable link. The Medium 
Access Control function controls the access signalling (request and grant) procedures 
for the radio channel, and the mapping of LLC frames onto the physical channel. See 
the references [3], [4] and [5] for further details about GPRS protocol stacks, PDUs, 
BSS contexts, flow control as well as common GPRS attach/detach and PDP context 

35 activation/deactivation procedures. 
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The SGSN 120 can provide the BSS 130 with infonnatioii related to ongoing user data 
transmission. The information related to one terminal is stored in a BSS context. The 
BSS 130 may contain BSS contexts for sevoral terminals. A BSS context contains a 
number of BSS packet flow (PFC) contexts. A PFC is created with DOWNLOAD- 
5 BSS-PFC (optional), CREATE-BSS-PFC and CREATE-BSS-PFC-ACK PDUs as 
described in flie reference [4]. A BSS packet flow context (PFC) is identified by a 
packet flow identifier.(PFI). There are four pre-defined packet flows identified by four 
reserved packet flow identifier values. One predefined packet flow is used for best- 
' effort service, one for signalling, one for SMS (Short Message Service), and one for 

10 LCS (Location Services). The BSS 130 shall not negotiate BSS packet flow contexts 
for these pre-defined packet flows with the SGSN 120. 

The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs sent 
by the SGSN 120 over the Gb interface to the BSS 130. There is a downlink buffer for 
15 each BVC m the BSS 130 identified by a BVCI. UNITDATA PDU contains an LLC 
PDU to be transmitted across the radio interface to a terminal. The principle of the 
existing BSSGP flow control procedures is that the BSS 130 sends flow control 
parameters to the SGSN 120 thus allowing the SGSN 120 to locally control its 
transmission output in SGSN to BSS direction (flow control is used only in the 
20 downlink direction). There are different levels of flow control: PFC, MS (Mobile 

/ Station; corresponding to a terminal) and BVC level. The SGSN 120 shall always 

apply BVC and MS flow control whereas PFC flow control is optional. The BSS 130 

y[ • controls the flow of UNITDATA PDUs to its BVC buffers by indicating to the SGSN 

the maximum allowed throughput for each BVC in a FLOW-CONTROL-BVC PDU. 

r...j 25 The BSS 130 controls the flow of UNITDATA PDUs to the BVC buffer of an 
individual terminal by indicating to the SGSN 120 the maximum allowed throughput 
for a certain TLLI (Temporary Link Level Identity) with FLOW-CONTROL-MS 
PDU. Additionally, FLOW-CONTROL-PFC PDU provides the SGSN 120 the flow 
control information regarding one or more PFC(s) of a given terminal. The SGSN 120 

. , 30 applies first PFC (if negotiated), then MS and finally BVC level flow control. If an 

; " LLC PDU to be included in a UNITDATA PDU passes all applied levels of flow 

- control it is forwarded to lower protocol layers to be transferred to the BSS. 

» > w 
• t* a 

Figures 5-7 disclose one option for enabling MBMS data routmg and flow control 
y 35 between the SGSN 120 and BSS 130 in accordance with the invention. In a general 

- - sense, a procedure partly congruent with the PFC concept described above can be 

applied by creating a MBPFC for each MBMS service, a group of services or a group 
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of terminals. From the SGSN's standpoint said group of terminals may, for example, 
belong to a same multicast group and reside behind a common BVC. The group, which 
typically contains at least two terminals, may receive data from a single source, e.g. an 
MBMS service, or from multiple sources. Occuring randomly it is still possible to have 

5 only one user (-one terminal) in the group though. In any case, the MBPFC is not 
logically connected to any individual terminal/associated with any individual TLU (or 
TMSI / P-TMSI). In multicast scenario the group for which the MBPFC is logically 
connected may be identified by a specific ID (e.g. a multicast ID). An MBMS specific 
PR such as the multicast ID can also be sent to the terminals belonging to the multicast 

10 group for identifying the incoming MBMS flow. However, this may not be necessary 
as the identification can also be done in some other way (MBMS ID etc). The main use 
of an MBPFC is according to the invention to serve as an addressing mechanism 
between the SGSN 120 and the BSS 130 and facilitate using flow control in the Gb 
interface. In the BSS 130 the MBPFC is mapped to an appropriate logical channel so 

15 that the announced MBMS service is sent on the channel indicated to users in the 
service announcement procedure, wherein network broadcasts information e.g. about 
the frequency, time slot, and possibly TDMA frame when a particular service is 
scheduled over the radio interface. 



20 The creation of an MBPFC can be executed as follows, see figure 5 A. The SGSN 120 
may initiate the procedure without any specific trigger from the BSS 130 side. For 
example, when the network establishes a new MBMS service or when the data is 
• actually to be transferred the SGSN 120 initiates the creation of an MBPFC relating to 

the service/multicast group. This can be done in conjunction with the service 
. 25 announcement or later on. The SGSN 120 requests for the creation of the MBPFC by 
/' sending a CREATE-MBPFC PDU 504 to the BSS 130 including a PR to be used for 

' the PFC identification. The BSS 130 (in the GERAN case the network elements within 

the BSS executing this task are the RNCs), responds with a CREATE-MBPFC-ACK 
PDU 508 or corresponding NACK if the MBPFC cannot be created. As the proposed 
30 method reminds of the one for creating a standard PFC with DOWNLOAD-BSS-PFC 
(optional), CREATE-BSS-PFC and CREATE-BSS-PFC-ACK messages, the existing 
standard procedure can also be exploited in this MBMS specific case, anyhow 
recalling that the essential difference is founded on a fact that the MBPFC is not 
logically connected to an individual terminal unlike the standard PFC. The network 
- 35 maps the PFC/PFI to a MBMS service/multicast group and it is also possible, although 
i.s" not advisable, to position all MBMS services into a single MBPFC. In that case 

different services cannot be treated independently and they may delay each other etc. 
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The SGSN 120 and BSS 130 maintain entities, e.g. memory tables, of existing MBMS 
service/multicast group<->PFC/PFI mappings in order to route and control the flow of 
the data to be tiransferred and, in the BSS 130, to further pass the received data over an 
appropriate (e.g. announced) logical channel to terminal(s) either as a broadcast or 
5 PTM (Point-To-Multipoint, e.g. multicast) transmission. 

Figure 6 discloses an option for the structure of messages applied in the figure 5A. 
CREATE-MBPFC PDU 504 includes fields for a message type identifier 602 e.g. a 
PDU type, PFI 604, ABQP 606 which is an Aggregate BSS QoS Profile (ABQP) 

10 defining the QoS agreed for the PFC (see the reference [5]) and optional data 608 such 
as optional IDs or group (e.g. terminals belonging to the same multicast group) 
definitions/identification etc. CREATE-MBPFC-ACK PDU 508 includes 
corresponding fields for a type identifier 610, a PFI 612 and ABQP 614 which may be 
restricted by the BSS 130 based on its current status and capabilities. Correspondingly, 

15 if NACK message is transmitted instead of ACK, a cause field can be included in the 
NACK to indicate the specific reason for rejecting the MBPFC creation as in a 
standard PFC case described in the reference [4]. 

MBPFC deletion can be executed respectively, see figure 5B. The SGSN 120 requeste 
20 the deletion when e.g. the service delivery has been ceased by transmitting a message 
DELETE-MBPFC 512 to the BSS 130 which acknowledges the request with 
DELETE-MBPFC ACK 516. It's also possible that the BSS 130 deletes the MBPFC 
' ; ' for some reason (e.g. lack of data tiransfer, memory or processing resources) and then 

i" informs the SGSN 120 about the executed deletion with a message, e.g. DELETE- 

25 MBPFC ACK 516. The message internals are not described here as they are mostly in 
- • conformity with the ones presented for the creation of an MBPFC including at least a 

message ID and TFI for the identification purposes. 

The SGSN 120 shall preferably perform flow contirol on each BVC, on each MBPFC 
30 and on some/all MBMS services as a whole, see figure 7. The flow control is 

performed first on each LLC-PDU (to be included in a UNTTDATA PDU) by an 
W MBPFC specific flow contirol mechanism 702, then by an aggregate flow control 

mechanism 704 and finally by a BVC flow control mechanism 706. BVC flow control 
i'-* (typically corresponding a cell) parameters concerning both standard PFCs as well as 

^ . 35 MBPFCs are received from the BSS 130 m a FLOW-CONTROL-BVC PDU described 
A in the reference [4]. MBPFC flow control parameters can in principle be received from 

the BSS in a FLOW-CONTROL-PFC message as in a normal PFC case but the 
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binding of the PFC with an individual terminal does not naturally apply. However, the 
BSS 130 may, for example, estimate an average profile of terminals receiving the 
services and inform the profile or relating parameters to the SGSN 120 for derivation 
of MBPFC specific flow control definitions. On the other hand, a set of rules may have 
5 been programmed in the BSS 130 indicating desired parameters (e.g. limit values for 
data leakage) for receiving services of varying type and based on that information, 
provide MBPFC specific parameters to the SGSN 120. As an third option, the SGSN 
120 may define MBPFC flow control parameters based on some service related data or 
its current status (e.g. load). An entity called MBMS service block 708 may be created, 

10 under which there would be a number of MBPFCs carrying different MBMS services, 
to form an aggregate flow control level 704 comprising at least one block 708 but one 
option is to perform only PFC and BVCI flow control resulting that the aggregate level 
704 in figure 7 does not exist. Secondly, if only a single PFC is created for all MBMS 
services as mentioned earlier, the situation remains the same. The SGSN 120 may 

15 construct the MBMS service blocks 708 by, for example, dividing the MBMS services 
into a number of groups (linked to blocks) based on the information about 
service/content type, content provider and service delivery requirements. This 
informationi, which can also be utilized in the creation of MBPFC flow control 
definitions, may be received, from a network element like the GGSN 122 or it can be 

20 derived internally either explicitly or implicitly from the MBMS data or relating 
ancillary information. 

A method applying the principles described herein is presented in figure 8. First, at a 
MBMS service start-up 802 or, for example, when the SGSN 120 has actually received 

25 data to be delivered to terminals, a PFI is defined 804 for the service identification and 
a corresponding PFC (MBPFC) is created 806 in the BSS 130, assigned by the SGSN 
120. In practice, the order of phases 804 and 806 is not relevant as long as the MBPFC 
and PFI are created as a result. Next, the radio resources between the BSS and 
terminals are reserved and set up in phase 808. This phase may include transmitting of 

30 MBMS notifications. Flow control is performed 810 before transferring the data over 
the Gb interface 812 from the SGSN 120 to the BSS 130 and finally over the air 
interface 814 to the terminals. If more data appears to be delivered 816 the phases of 
flow control 810 and data transfer 812, 814 may be repeated. When no more data 
exists, for example, for a predetermined time period or the service is ramped dovm, the 

35 MBPFC may be deleted 818. It should be noted that the order of the aforementioned 
phases may be changed and some phases can even be altered or combined together 
without diverging firom the concept of the invention. For example, phase 808 may be 
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executed just before phase 814 if logical channels/radio resources are to be allocated in 
connection with actual data delivery. 

The scope of the invention is disclosed in the following independent claims. However, 
utilized messages, network elements, method and procedure steps etc may vary 
depending on the current scenario, still converging to the basic ideas of the invention. 
Therefore, the invention is not strictly limited to the embodiments described above. 
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Claims 

1. A method for routing MBMS (Multicast/Broadcast Multimedia Service) service 
data from a first network entity (120) to a second network entity (130), characterized 
in that said mettiod comprises the steps of 

5 -defining a PFI (Packet Flow Identifier) associated to at least one MBMS service 

or a group of terminals (804), 

-creating a PFC (Packet How Context) for said MBMS service or group of 
terminals identified by said PFI (806), 

-transferring the MBMS service data over the Gb interface by utilizing said PFC 
10 (812). 

2. A method of claim 1, characterized in that it further comprises a step wherein 
the PFC is mapped to an appropriate logical channel indicated by the MBMS service 
announcement (808). 

3. A method of claim 1, characterized in that it further comprises a step, wherein 
15 the first network entity performs flow control of MBMS data on PFC and BVC 

(BSSGP Virtual Connection) levels (810). 

4. A method of claim 3, characterized in that said flow control is additionally 
performed on a level (704) located between said PFC and BVC levels, said level (704) 
comprising at least one block (708) whereto at least one PFC is logically connected. 

20 5. A method of claim 1, characterized in that terminals in said group of terminals 
belong to a same multicast group. 

6. A method of claim 1, characterized ia that terminals in said group of terminals 
receive data from at least one conunon source. 

7. A method of claim 1, characterized in that said creation of the PFC comprises a 
25 step wherein a PFC request (504) is transmitted to a network entity (130) performing 

said creation. 

8. A method of claim 3-4, characterized in that at least part of the flow control 
parameters are received from the BSS (Base Station System) or GGSN (Gateway 
GPRS Support Node). 
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9. A method of claim 1, characterized in that said transferred data is identified by 
said second network entity (1 30) on the basis of said PFI. 

10. A method of claim 1, characterized in that the order of steps for defining a PFI 
(804) and for creating a PFC (806) is swapped. 

11. A system comprising a Gb interface between a first (120) and a second network 
entity (130), characterized in that in order to route MBMS service data over said Gb 
interface said first (120) and second (130) network entities are arranged to negotiate a 
common PFI (Packet Flow Identifier) for said MBMS service or a group of terminals 
and said second network element (130) is arranged to create a PFC (Packet Flow 
Context) for said MBMS service or group of terminals. 

12. A system of claim 11, characterized in that said system is arranged to perform 
flow control of said MBMS data at least on PFC (702) and BVC (706) (BSSGP 
Virtual Connection) levels prior to the transmission over the Gb interface. 

13. A system of claim 12, characterized in that said flow control fiirthCT comprises a 
level (704) located between said PFC (702) and BVC (706) levels, said level (704) 
comprising at least one block (708) whereto at least one PFC is logically connected. 

14. A system of claim 11, characterized in that said first network entity is 
substantially the SGSN (Serving GPRS Support Node, 120) and said second network 
entity is substantially the GERAN (GSM/EDGE Radio Access Network, 130). 

15. A system of claim 11, characterized in that said first network entity (120) is 
arranged to request said creation of the PFC from said second network entity (130). 

16. A system of claim 11, characterized in that it is arranged to map the PFC to an 
appropriate logical channel indicated by the MBMS service announcement. 

17. A system of claim 1 1, characterized in that terminals in said group of terminals 
belong to a same multicast group. 




(57) Abstract 

The invention relates to a method and a system for routing 
and controlling packet data flow. A method for routing 
MBMS (Multicast/Broadcast Multimedia Service) service 
data from a first network entity to a second network entity 
is presented. A system comprising a Gb interface between a 
first and a second network entity arranged to route MBMS 
service data over said Gb interface is presented. The routing 
is enabled by defining a PFI (Packet Flow Identifier) and by 
creating a corresponding PFC (Packet Flow Context) for 
said MBMS service. 
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